Network computing has grown at a phenomenal rate over the last decade. In a network computing environment, a user has access to the computing power of multiple computers located on a network. Sun Microsystems Inc., a leader in network computing, even devised a marketing campaign around the slogan "The Network Is the Computer".TM. to emphasize the commercial success of this growing segment of the computing market.sup.1. Recently, this slogan has become reality as millions of users have tapped the computing resources available from the thousands of computers available on the Internet and the World Wide Web.
 FNT 1. The Network Is the Computer, Sun, the Sun logo, Sun Microsystems, Solaris, Ultra and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. UNIX is a registered trademark in the United States and other countries exclusively licensed through X/Open Company, Ltd.
One of the more interesting areas of research in network computing concerns how to simultaneously and efficiently transmit information to multiple nodes on a network. In particular, many people are researching multicast protocols. A multicast protocol allows a transmitter node on a network to send the same data packets to multiple specific receiver nodes on a network without using separate point-to-point connections. The point-to-point connections, also referred to as unicast connections, are not desireable because each point-to-point connection establishes a seperate logical network connection between the transmitter node and each receiver node on the network. The seperate logical network connection requires seperate network resources, such as a seperate IP (Internet Protocol) connection, to establish the actual connection as well as additional bandwidth to transmit multiple copies of the same packet. This wastes network resources because the information being transmitted over each network connection is identical.
The multicast protocol enables the transmitting node to transmit a series of data packets to multiple receivers without establishing a seperate network connection for each receiver node or sending duplicate packets of the data over a network. Instead, the multicast protocol sends a single stream of packets over the network in which only members of the multicast group are able to read. Multicast is an improvement over unicast protocols using numerous point-to-point channels because multicast does not send redundant packets of information. Multicast is also advantageous because only a predetermined list of multicast members can receive the multicast transmission.
An increasing number of practical applications available on the Internet such as live stock quotes, video conferencing, white board applications, electronic commerce, remote learning, and other group communications are migrating to multicast protocols to resolve these network bandwidth deficiencies. These applications will invariably contain sensitive and confidential information about their users. Consequently, packets transmitted over these multicast networks should be encrypted to prevent eavesdropping by individuals not in the multicast group.
Accordingly, there are at least two general concerns in designing robust cryptographic systems for encrypting information distributed on a multicast network: encryption and key management. First, the encryption technique used to encrypt the information must not be easily compromised by an unauthorized eavesdropper. To evade such eavesdroppers, algorithms such as Data Encryption Standard (DES) are used to to encrypt data using a cryptographic key. The protection against hackers and interlopers lies in the length of the cryptographic key in addition to the complexity of the encryption algorithm. Generally, a longer cryptographic key requires more computer resources and more time to decrypt. Thus, by changing the cryptographic keys at regular time intervals, hackers will not have sufficient time to compute the cryptographic keys.
The second, and often more difficult, aspect of cryptographic systems lies in the key management. Key management typically involves secure key distribution and scalability. Essentially, key distribution must be secure or a hacker will obtain the key and security will be compromised. Moreover, in a large multicast network the key distribution must scale well so that a large number of users can obtain the keys quickly and efficiently. The size of the multicast group and request for keys should not degrade performance of the cryptographic system. Establishing management techniques which scale well for large multicast groups has remained a problem in cryptographic systems.
Typically, modern cryptographic systems use key management to manage distribution of a traffic key and a key encrypting key. The traffic key is a key used to actually encrypt the data being transmitted across a network while the key encrypting key is a key used to encrypt the traffic key and prevent it from being discovered enroute to a receiving node. Both of these keys must be distributed in a manner which scales to multicast networks with a large number of multicast members.
Unfortunately, existing key management techniques often use a single server, sometimes referred to as a Group Coordinator or GC, to distribute the traffic keys or key encrypting keys associated with a multicast transmission. The GC maintains secure key distribution but can be overwhelmed if the requests are too frequent and too numerous. In some cases, requesting nodes geographically distant from the single server will experience delays in receiving a key and can miss part, if not all, of a multicast transmission in the interim. In a worst case, a large multicast group can suddenly overload the GC with requests such that certain members of the multicast group never receive any keys. Members of the multicast group without the appropiate keys would be excluded from the multicast transmission entirely. Key management techniques must be improved to scale with large multicast groups.
A multicast extension using the SKIP 1 (Simple Key Management for Internet Protocols) protocol scales well for distributing the traffic key but does not scale as well for distributing the key encrypting key. In multicast SKIP, the traffic key is used to encrypt data in a packet. The traffic key is an inline traffic key because it is included with each packet. To keep the traffic key confidential, SKIP for multicast IP (Internet Protocol) encrypts the traffic key using a key encrypting key referred to as a Group Interchange Key or GIK.
 FNT 1.Solstice.TM. PC-SKIP.TM. SunScreen.TM. SKIP are trademarks of Sun Microsystems, Inc.
Distribution of the traffic key in multicast SKIP scales well to large multicast groups because each member of the multicast group receiving a packet has a copy of the traffic key. However, the distribution of the GIK does not scale as easily. Unlike the inline traffic key, SKIP uses public-key key distribution to distribute the GIK with a single server known as the Group Controller or GC. When membership in the multicast group gets too large and geographically spread out, the GC can have difficulty distributing the GIK. Thus, while traffic key distribution using an inline traffic key is highly scalable, the distribution of the GIK from a single GC remains only moderately scalable. Details on multicast SKIP are included in the paper entitled "Design and Implementation of SKIP", authored by Ashar Aziz and Martin Patterson, Jun. 28, 1995.
Other existing key-management techniques which have not addressed scalable key distribution techniques also suffer problems similar to the ones discussed above. One technique called Group Key Management Protocol (GKMP.sup.1) contemplates that the GIK (referred to in GKMP as a "traffic key") can be distributed by individual members of a multicast group but does not indicate an efficient and secure technique for selecting members of the multicast group to distribute the key encrypting key. Further, GKMP does not discuss a secure means in which key requests for the GIK are fulfilled. Essentially, the GKMP technique can still overload a group owner or group coordinator with key requests because the load associated with fulfilling these key requests is not necessarily distributed evenly over multiple servers.
 FNT 1.IETF Internet-Draft Group Key Management Protocol Architecture, Hugh Harney and Carl Muckenhirn, SPARTA, Inc. Jun. 18, 1996
Another technique discussed in RFC 1949 addresses multicast key distribution in the context of a specific multicast routing protocol using Core Based Trees (CBT). This scheme has the drawback of tying the key distribution to a specific multicast routing protocol, namely CBT. Moreover, it also suffers from the problem of having to involve and trust entities whose role is determined by virtue of the multicast routing protocol. Unfortunately, the CBT multicast routing protocol determines the efficiency of transmitting multicast data based on a particular route and not based on which nodes on the network are to be trusted as a secure node for distributing a key.
What is needed is a technique for managing keys on a secure network which scales based on the load and geographic location of a rapidly growing multicast group. This technique should not compromise the level of security during transmission or reduce either forward or reverse secrecy.